1. Field of the Invention
This invention relates to the field of information and storage management and, more particularly, to storage and retrieval of large binary objects.
2. Description of the Related Art
Client/server object storage systems have been used to store and manage a wide variety of digital objects such as documents, graphics, audio, video, spread sheets and word-processing text. Such digital objects are known generally as binary lo large objects (blobs).
A conceptual view of a conventional client/server system is shown in FIG. 1 and includes a library server 10, one or more object servers 20 and a library client 30. Each of the library and object servers and the library client includes an information store. That is, the library server 10 includes a library catalog 12, the is object server 20 includes an object store 22 and the library client 30 includes a client cache 32, as shown in FIG. 2. Also, a communications isolator (not shown) is included which allows the library server, object server and library client to communicate with one another without concern for complex communications protocols. The library server, object servers and library clients are connected by a communications network, such as a wide-area network (WAN), but also can be locally connected via a local area network (LAN).
In the conventional library client/server system the library client is typically embodied in a workstation, such as a personal computer, and the library and object servers are typically embodied in a host processor: generally a mainframe computer.
The library clients 30 each send requests to the library server 10 to store, retrieve, and update objects stored in one or more of the object servers, and to update and query the object indices and descriptive information stored in library catalog 12. Library client requests are generated by library patrons. These patrons are users who have been granted privileges for the use of the library system.
Two types of library servers have been used, a host based library server (HBLS) and a LAN based library server (LBLS). The HBLS, is a program which can be implemented in a mainframe computer in an IBM MVS/ESA (Multiple Virtual Storage/Enterprise Systems Architecture) environment running under the Customer Information & Communication System (CICS). The library catalog with which it interacts can be implemented with an IBM DATABASE 2 (DB2) database.
Before a library client request is processed, library server 10 checks library catalog 12 to ensure that the patron's name and password are valid. Next, the library server ensures that the patron has been granted the appropriate privileges to perform the requested action. Each patron is assigned a set of privileges by a system administrator. An example of a library privilege is the ability to delete objects.
Finally, the library server checks to ensure that the object's owner has granted the patron the privileges needed to do what is requested (e.g., update the object). The owner of an object is the patron who first stored the object. When an owner stores an object that owner must specify which other patrons are to have access to the object.
Objects stored in the library system can be checked out by a patron for a specified period of time. This feature can be used to ensure that one patron's updates to an object are not overwritten by another. While an object is checked out by a patron, other patrons can retrieve the object and view it, but they cannot update it. In typical implementations, there are groups of individuals who need access to the same objects. Therefore, to simplify the process of granting access to objects a system administrator can define patrons as members of a group. When a patron is defined as a member of a group, that patron is able to access any object for which the group has been granted privileges. Additionally, patrons can access objects for which they have been specifically granted individual privileges. A patron can set default groups whose members will have access to the objects the patron stores. When patrons store objects, they have the option to use this default group, to grant specific privileges to groups and individual patrons, or to do both.
If a library client request involves the storage, retrieval, or update of an object, library server 10 forwards the request to the object server 20 that contains or will store the object(s) referred to in the request based upon information provided by library catalog 12. If the library client request is a query of the information stored in library catalog 12, library server 10 will interact only with library catalog 12 and will not contact object server 20.
The library catalog is analogous to a conventional library's card catalog. It is a single set of database tables which contain an index of all the objects stored in the library system. In addition, it can store information such as textual descriptions for each object, information on the type of object (e.g., image object, spreadsheet, text document), library patron names and privileges, access authorization data for each object, links between objects. The library catalog can also store a virtually unlimited number of property type/property value pairs for each object (e.g., name/John, Age/35, Address/1 Greenway Drive). These property type/property value pairs are known as an object's properties.
The library server contains a parts table 14, as shown in FIG. 3, which resides in the library catalog 12. For each part in the library system library server 10 stores information about that part. As shown in the parts table 14 in FIG. 3, the information stored for a part includes an item identifier (ID), a part number, a representation type (REP type) and an object server ID.
When a part is stored in the conventional client/server library system, library server 10 assigns an item ID and a part number, which are 16 bytes and 4 bytes long, respectively. The item ID is a unique identifier for an item to which the part belongs. For example, an item could represent a folder in which the part represents a document within that folder. Likewise, the part number is a unique identifier for that part.
The REP type field can be used to indicate the type or class in which the part is classified. For example, if the part is an image stored in a TIFF format, the REP type for that part could indicate that the part is a TIFF formatted image.
An object server 20 maintains objects stored within the library system. Objects are stored or retrieved from an object store 22 by object server 20. Object server 20 receives requests from library server 10 and communicates with library client 30 to complete the requests. Such a library system can contain several distributed object servers. The object server field in the library server's parts table indicates the identifier for the object server which owns the part. For example, if the part is stored on object store 22 of object server 20, the object server ID field will contain the identifier for object server 20.
Each object server contains an object server table 24 as shown in FIG. 3. The object server 20 uses object server table 24 to manage storage of parts in its storage areas, such as the object store 22. Object server table 24 also contains the same item ID, part number and REP type for the part as does the library server parts table 14. The object server table also contains a file name for the part 28, which indicates the location in object store 22 of stored part 28.
In the conventional library client/server system, object server 20 communicates with the library client 30 via the client cache 32. That is, when an object server retrieves an object from library client 30, it retrieves the object from the client cache 32. Similarly, when sending an object to library client 30, object server 20 places a copy of the object in client cache 32.
Two types of object servers have been used, a host based object server (HBOS) and a LAN based object server (LBOS). The HBOS is a program implemented on a mainframe computer, for example in a MVS/ESA environment running under CICS. It interacts with the IBM Object Access Method (OAM) to provide object storage. The LBOS is a program implemented in a workstation, such as in an OS/2 environment, and provides object storage on a LAN.
When a library patrons's privileges are defined a default object server can be set for the patron. When a patron stores an object, it will be stored in the default object server for that patron. If it is later determined that an object or a group of objects should be relocated to a different object server, a client application can cause those objects to be moved from one object server to another.
An LBOS can be located on any workstation having sufficient hardware resources and is connected to the library server. Furthermore, an LBOS can be located at a site remote from the library server and local to the user. This allows selected objects to be stored close to a remote group of library patrons who will frequently use these objects. This capability is called distributed object storage. Distributed object storage helps to reduce the costs associated with sending objects over telecommunications lines and provides better performance in storing and retrieving objects.
The HBOS interacts with the IBM OAM to implement an object store that is maintained as a set of IBM DB2 tables, such as the object server table 24 discussed above. These DB2 tables can be monitored, backed up, and recovered using standard database utilities. OAM is capable of managing its information store using a s combination of direct access storage devices (DASD) and write once read many (WORM) optical storage.
LBOS implements its object store by using a combination of the LBOS workstation hard drives and an optional optical library subsystem (often called an optical jukebox). The optical library supported by LBOS is capable of storing optical cartridges internally. Shelf-resident optical cartridge support is also provided, thus greatly expanding the storage capacity of the optical server. LBOS controls the migration of objects between the workstation hard drive, which functions as a staging area, and optical storage. Because a workstation's hard drive can access stored information faster than an optical jukebox, LBOS ensures that newly stored objects and objects that have recently been retrieved are maintained on the workstation hard drive. As the workstation hard drive becomes full, LBOS removes those objects to optical storage that has been least recently accessed to free storage space for new objects. A single drive optical drive can also be attached to LBOS to provide a transaction log as a backup mechanism for the optical library.
LBOS includes a variety of storage administration functions, such as transaction logging and the ability to write out duplicate copies of images and files to support full backup and recovery.
The library client 30 is the interface through which application programs can submit requests to the library system. These can include requests to store objects, update/add descriptors to objects, delete objects and query information in the library catalog. Library requests can be submitted through the library client either individually or in batches.
The client cache 32 is a specialized function, implemented on a user's workstation. The cache is used to locally hold copies of objects that have been stored to or retrieved from the object server. These local copies allow very fast access to objects and provide a means for communicating between the library client and the servers. When a library client requests a copy of an object from the library server, the library server causes a copy of that object to be sent from the object server which owns it to the library client that requested it. The object is stored in the client cache of the requesting library client. When library request orders are submitted by library client 30 to library server 10 a copy of the request is also stored in client cache 32.
FIG. 2 illustrates the data flow in a conventional digital client/server library system. A library client, such as library client 30, can be located remotely from the library server 10 and object server 20. Typically, the library client 30 is connected to library server 10 and object server 20 via a WAN. Moreover, object server 20 may be connected to library server 10 via a WAN.
When a requesting library client 30 requests an object, or blob, it sends a request 1 to library server 10. Upon receipt of the request library server 10 consults the parts table 14, among other tables, in the library catalog 12 and determines which object server owns and has the requested object stored in its object store 22. Here, the owning object server is shown as object server 20 to which library server 10 issues a request 2 which contains the item ID, part number and REP type of the requested part. Upon receiving the request, object server 20 retrieves the blob from object store 22 by consulting its object server table 24 and sends a copy of it to client 30. The double line 3 shown in FIG. 2 indicates a copy of the blob which is transmitted from object server 20 to requesting client 30. Object server 20 stores the blob in client cache 32. When the blob is successfully transmitted to client cache 32 object server 20 sends a response 4 to library server 10 upon successful transfer of the blob to client cache 32. Library server 10, in turn, sends a response 5 to requesting library client 30 indicating to the client that the blob was successfully transferred, which allows the client to retrieve the blob from client cache 32 for use by a client application.
When an application program submits a request for storage of an object in the conventional library system library client 30 creates a copy of the object in its client cache 32 to allow the appropriate object server 20 to retrieve the object. The library client then sends a storage request 1 to library server 10. Included in the storage request is a handle to the object stored in the client cache 32. The handle is an identifier which is used to locate the object in the client cache.
Upon receiving the storage request 1, library server updates tables in library catalog 12, including the parts table 14 as shown in FIG. 3, to identify the object server 20 in which the object is to be stored. Typically, the object server is selected by default based on the user's identity. Library server 10 then sends a request 2 to object server 20 to retrieve the blob from the client cache 32 and store it in the object store 22, in which library server 10 passes the handle of the object stored in client cache 32 and the item ID, part number and REP type of the part.
The object server 20, upon receiving the request 2 to retrieve a copy of the object stored in client cache 32 then retrieves a copy of the object 3, or blob, and stores that copy in object store 22, generally for archival purposes and updates its object server table 24 accordingly to indicate a file name for the blob stored in object store 22. As shown in FIG. 3 the file name uniquely identifies the location of the blob stored in object store 22.
Upon successfully storing a copy of the blob, object server 20 sends a response 4 to library server 10 to notify it that the object was successfully stored. Library server 10 then updates its tables including the parts table 24 to indicate that the object is successfully stored in object server 20. The library server 10 sends a response 5 to library client 30 indicating that the object was successfully stored so that the library client can take further action based on the fact that the object was successfully stored in object store 22, such as deallocating memory resources for that object in client cache 32.
The conventional client/server library system has mechanisms, as described above, to efficiently store and retrieve parts that range up to about 10 Mb. However, in the conventional library client and object server an object, or blob, must be totally constituted in memory in several places within the system as it is being processed on its path to file storage. When objects get too big for a given configuration of available memory and network access, they cannot be processed because not enough system resource is available to create an in-storage copy. The external symptom when these resource constraints are reached is a timeout of the library client that is waiting for a response from the server. Even in cases where the timeout values are set very high and the object is successfully stored the response time to move it is unacceptably slow.
File systems are known which divide a file into blocks which are smaller than the entire file in order to store the file information on a storage device, such as a disk drive. For example, the Unix file system stores a file on a disk in data blocks of fixed size (see A. Silberschatz, Operating System Concepts, pp. 488-96, 1989). These data blocks, however, have a fixed size, such as 8,192 bytes. Since these blocks have a fixed size, some known file systems employ two difference block sizes: a large block size for most of the blocks used, and a smaller block size, such as 1024, in order to minimize fragmentation. Accordingly, the Unix file system stores a file in small blocks which are stored on the disk device. The Unix system employs an index node which is called an inode, which contains a record concerning the particular data blocks in which the file is stored. The inode contains pointers to the data blocks which comprise a file.
A problem with known file systems, such as the Unix file system, is that data blocks are limited to fixed sizes and cannot be readily changed after a file has been stored. Accordingly, changes in stored files can cause a change to data within a particular block which causes a ripple effect throughout the blocks stored, such that the file data for the entire file needs to be stored again in order to have the data redistributed throughout the allocated blocks.
Other file systems, such as the high performance file system (HPFS), disclosed by Letwin in U.S. Pat. No. 5,371,885, store data in variable length record forms. For example, Letwin shows in FIG. 5c, and discusses in column 7 through 9 an FNODE which contains an allocation structure 546 which points to a plurality of sector runs. Sector runs are defined to be sets of contiguous sectors on a disk. The allocation structure of the FNODE points to the beginning of a sector run and indicates the length in sectors corresponding to the number of contiguous sectors in that sector run. Accordingly, in the HPFS system a file is still allocated in terms of fixed size units, namely sectors, and is limited to defining units of storage which are physically contiguous on a device, such as a disk drive. The HPFS system does not allow for arbitrarily varying the length of the sector runs since the sector run representation in the allocation structure 546 is related to the sectors which are physically contiguous with one another on a disk. Accordingly, even the HPFS system would suffer from the above described problems.